In my last blog I highlighted how services could be combined and utilized in BPM solutions. In this quick blog I would like to see how Event Driven Architectures (EDA) can make use of services.
EDA is a strategy that revolves around the concept of designing systems that create, process, and react to events. An event can be a change in state, a condition being met, or the detection of an action being performed. The architecture tends to employs four main participants:
- Event Producer – Generate Events Representing what was Detected
- Event Consumer – Receives Events and Takes Appropriate Action Based on the Event Contents
- Event Channel – Mechanism to Deliver Events to Interested Parties
- Event Processor – Perform the Necessary Meaningful Work in Response to an Event including Aggregation, Correlation, Filtering, etc.
Event generation can be done in a number of ways, including database triggers, IoT sensors, and various types of detection and measuring devices. Event processing can be accomplished using specialized infrastructure known as a Complex Event Processing (CEP). It is configuration-driven software that can process large volumes of events looking for patterns that match predefined conditions. A CEP can be used to process either simple or complex (multiple correlating) events. When meaningful event conditions are detected, it can notify interested parties.
Notification can occur via a direct invocation of business logic, or via a publish and subscribe mechanism. The latter method is preferred as it establishes an architecture pattern that is loosely coupled and easily expandable. It allows multiple downstream processors to come and go based on business needs.
Since processing involves performing (orchestrating) a number of activities, the most recommended implementations are business processes. However, SOA Services could act as downstream processors in cases where simple activities need to be performed.
The intersection of EDA and SOA primarily pertains to the downstream processor.
As shown above, it can take many forms, including that of a business process or SOA Service. As a result it is easy to see where EDA, SOA, and BPM might coexist. In addition, the publish / subscribe mechanism can be exposed as a set of SOA Services in order to create a universal, product-agnostic interface.
One could argue that the other types of actors in an EDA solution could be developed as SOA Services. For example, the Event Processor could be a type of SOA Service that receives and processes events. However, there are factors to consider, including:
- The technology used to detect when an event occurs. Events can be generated by sensors, measurement devices, and other low level devices that receive inputs in ways other than through APIs.
- Such event generators may not have the capabilities required to invoke SOA Services. They may only be able to send events in very simple forms.
- The frequency of event generation can be much greater than the frequency of downstream processing. If only a small fraction of events actually require any action be taken, then a large number of SOA Services will be invoked to perform a small amount of work. This would be an inefficient architecture pattern.
OK that is enough for now. In my next blog I think I will discuss how to utilize services in a MDM solution.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 